IBIS Macromodel Task Group

Meeting date: 04 December 2018

Members (asterisk for those attending):
ANSYS:                        Dan Dvorscak
                            * Curtis Clark
Cadence Design Systems:     * Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC:                        David Banas
GlobalFoundries:              Steve Parker
IBM                           Luis Armenta
                              Trevor Timpane
Intel:                        Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
                              Stephen Slater
                               Maziar Farahmand
Mentor, A Siemens Business:   John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
SiSoft:                     * Walter Katz
                            * Mike LaBonte
SPISim:                     * Wei-hsing Huang
Synopsys:                     Rita Horner
                              Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:
- Arpad noted that the only ATM meetings we expect to cancel in the next few
  weeks are those on December 25th and January 1st.  The January 29th meeting
  will be cancelled because of DesignCon.

-------------
Review of ARs:

- Randy to investigate if/why/how a clock waveform input might be used.
  - In progress.  Randy noted that internal discussions continue.

- Michael M. to investigate if/why/how a clock waveform input might be used.
  - In progress.
  
- Michael M. to check with IP experts on whether DC_Offset is useful for Tx.
  - In progress.
  
- Walter to update the DC_Offset BIRD draft.
  - Done.   Introduced as BIRD197 at the previous Friday's Open Forum meeting.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the November 27
meeting.  Mike L. moved to approve the minutes.  Randy seconded the motion.
There were no objections.

-------------
New Discussion:
DC_Offset BIRD197:
Arpad noted that BIRD197 had been introduced at the last Open Forum meeting, and
that Bob had raised some editorial issues.  Walter noted that he had begun a new
draft incorporating Bob's changes.  Bob noted one additional typo "SC_Offset"
instead of DC_Offset.  Bob also suggested that we carefully distinguish between
the Definitions: and Usage Rules: sections.  He noted that the sentence in the 
Definitions: section describing the EDA tool's responsibility should probably
be in the Usage Rules: section.  Walter removed the offending sentence from the
Definitions: section.  Radek suggested replacing "average" with "mean value" and
Walter made the change.  Bob noted some additional spacing and formatting
issues, which Mike L. said the Editorial Task Group would address.  Bob
suggested the new draft be sent to ATM for further review as BIRD197.1 draft 1.
Walter agreed and took the AR to send it out.

DDR5 related topics:
Arpad noted that Ted Mido's presentation to the Open Forum meeting had offered
a few suggestions for handling some of the DDR5 challenges.  Arpad asked if we
might embrace some of those suggestions by turning them into BIRDs or if they
would all be handled at the tool level?  Walter noted that most substantive
proposal was for a new parameter to indicate that clock_times would be used as
an input to the Rx and would contain the times of the DQS transitions.  Walter
noted that people generally agree that this mechanism could be used to get clock
ticks into the Rx.  Walter said the questions remain: what do they mean to the
.dll and the EDA tool, and who is responsible for generating them and
determining the DQ to DQS skew?  Walter noted that Ted also did not have a ready
answer to the skew question.  Walter noted that Fangyi had been leaning toward
a component model.  Walter thought the component model would control the DQS,
and that the AMI Tx model could serve as the component model and output the
clock ticks and control the DQ to DQS skew.  Walter noted the presence of many
interesting detail questions related to controlling DQS and the skew to one or
more DQ lines.

Arpad noted that we are currently waiting for more feedback from Randy and
Michael M. to help define the problem.  Walter agreed, and said we are waiting
for someone to propose a way to generate DQS that we all agree solves the
problem(s).  He noted that the mechanism for implementing the passing of clock
ticks (as mentioned above) is fairly straightforward.  However, he noted that
there had been some objection to earlier proposals to use the AMI_parameters_out
argument in a bi-directional way, and this was similar.  Radek noted that using
clock_times as an input was less problematic because the EDA tool was already
responsible for allocating the memory for clock_times.  With AMI_parameters_out,
the issue with proposing bi-directional usage was that the model was responsible
for allocating the memory in the original output direction, and the EDA tool
would have to allocate the memory for the input direction.

Ambrish noted that delay between DQ and DQS could be determined by looking at
the step responses.  Walter agreed, but noted that the skew between them is
changed by the controller during training.  Walter noted that the model has to
figure out the skew one way or another, and then there are impairments (jitter)
for DQ vs. DQS.  The AMI jitter parameters can deal with the impairments.

Randy noted that Ted had some slides dedicated to correlated vs. uncorrelated
jitter between strobe and data.  Randy noted that one of the things they were
investigating as part of the clock waveform AR was whether the existing AMI
jitter parameters could adequately model the jitter in the system and avoid any
double counting if you have jitter that is correlated between data and strobe.
Walter noted that Ted had mentioned Sj, but Walter said he thought Sj went away
because it's clock forwarded.  Randy agreed that you might be able to track out
certain parts of Sj but maybe not all of it.  Arpad asked if it looked like we'd
need new jitter parameters.  Randy said that's what they were investigating, and
so far the existing parameters were sufficient, but there might be some
limitations to using them.

Mike L. agreed that so far we hadn't yet seen any reason for an IBIS change,
and he said that he thought what Ted was suggesting was largely for EDA vendors.
He noted, however, that it would be good to work with Ted if we got to the point
of a BIRD, because Ted has thought about the issues and has some examples and
simulation results.

Walter said that to know what the issues are and how to account for them all we
probably need lab data.  We need to correlate with lab data to fully vet any
ideas, and right now no one can say when they'll have real hardware and lab
data.

C_comp modeling:
Randy noted that the enhanced C_comp BIRD draft is in good condition and is
generally updated to BIRD189 and the Si_location and Timing_location changes of
BIRD191.2.  Randy reviewed his most recent presentation on the topic (see ATM
archives from June 5, 2018).

slide 5: Enhanced C_comp model for traditional connections.  This BIRD allows
one to replace C_comp with a black box model using IBIS-ISS or Touchstone.  In
order to avoid breaking simulators, the [C Comp Corner] must be used and the
values it provides are used by the EDA tools for their K(t) compensation.  The
new model can be connected to the pad node and the various reference nodes.

slide 6: Series elements within a buffer.  The extra nodes in this example allow
for filtering or series resistance between the pad node and the input buffer
location.  You could probe at the input buffer after the C_comp model (the
new Buffer_I terminal).  Bob had suggested the possibility of having two
different models, one for output mode and one for input mode.  That's written
into the BIRD, but one of the things we discussed before was whether we really
wanted to allow a series element that creates the Buffer_O node.  We discussed
removing that option to simplify this BIRD and having model makers use BIRD189
to represent the on-die interconnect instead of putting that in this C_comp
model.

Walter noted that in the drawing the Pull_up and Pull_down curves seem
to be shown in the upper triangle (I-V & K-T in drawing).  When it's a receiver
those are turned off.  This picture implies the Power_Clamp and Gnd_Clamp
curves apply to the input.  We would need clarification to avoid confusion
about how to implement this.  Arpad asked about Submodels and where they would
be applied in this figure.  Randy clarified that when you have an Input you can
use the I/V curves for Power_Clamp and Gnd_Clamp and any non-driving Submodels.
The new Buffer_I node is just where the Input buffer sits, but everything is
still there in terms of the normal Input [Model].  Arpad noted that he thought
part of the reason for the series elements was to model a series impedance that
existed for the Input path but was not in the Output path.  Randy agreed.  Arpad
asked if the clamping diodes would be viewed through that series impedance or
if they would be more effectively clamping at the driver triangle.  Randy said
this was a good point, and he noted that clamping (like ESD protection)
typically exists very close to the pad.  Arpad noted that for transistors the
clamping often came from a parasitic diode between the substrate and the source
or drain of the transistor.  This might make it impossible to separate the
clamping behavior from the driving I/V curves.  So, the clamps should be kept
in the driving triangle unless the clamps are a special separate ESD circuit.
Randy noted that he's considering a change to remove the Buffer_O terminal from
this option.  This would mean we can't have any series element to separate the
driving transistors from the pad, (the Buffer_O and pad collapse to one node)
but that's reasonable because you could represent such a circuit using BIRD189
instead.

Bob noted that Submodel is separate from this proposal and additive.  Arpad
noted that the question (for slide 6) was where it was to be added.  Bob also
noted that every driver has the Input model as a load.  Referring back to slide
5, Bob noted that in reality the C_comp might be different in Input mode vs.
driving mode.  He noted that this is something IBIS currently doesn't support,
and that he thought it would be a mistake not to address it with this improved
C_comp proposal.  If we are adding more complex C_comp models, we should address
the fact that C_comp might differ for different modes.  Bob also noted that the
various reference nodes also connect to the buffer triangles themselves.  Randy
agreed and said that if it was confusing that these connections were not shown
explicitly then he could consider changing the slide.

Arpad asked when Randy hoped to get this into the spec.  Randy said he would
want it to be part of 7.1.

Bob asked if it was a concern that this new C_comp could not be used with
[External Model] (when [External Model] is used it overrides any regular [Model]
constructs).  Arpad and Radek noted that [External Model] with multi-lingual
would allow the model maker to do anything they wanted.

slide 7:  Randy noted that we had previously discussed whether we wanted the
additional complexity to support a C_comp model that tied together two pins
from a [Diff Pin] pair.  However, he noted that this might support true
differential models with series elements, etc., between two buffers, but that
this might break some EDA tool assumptions.  Arpad noted that aside from true
differential [External Model]s, IBIS wasn't very good at differential models.
It's one thing to have pseudo differential independent buffers, but adding all
the differential capacitance, etc., between them seemed a more important feature
of this figure than series elements.  Walter said he had the same question about
this figure that he had noted earlier.  Where are the I/V curves connected,
given that Buffer_O_pos and Buffer_I_pos aren't the same node?   Randy clarified
that for this picture all I/V curves would be connected to Buffer_O_pos.
Buffer_I_pos is simply a node you can probe to see filtering effects that would
be present at the Input circuitry.

Arpad suggested the drawing was incorrect because the Input looks like a true
differential receiver (one buffer triangle), but the outputs are shown as two
separate triangles.  Randy said the [Diff_Pin] statement says the two pins are
a differential pair, and you measure them with a differential voltage.  Arpad
acknowledged what Randy was trying to represent in the picture, but said he was
afraid someone might misinterpret the drawing to mean the receiver was a true
differential and the drivers were pseudo differential.

Bob noted that IBIS traditionally has problems with true differential modeling
because of single-ended test fixturing assumptions.  If we added too many
features and nodes to this BIRD, we might make model extraction physically
impossible.  Walter noted that at this point, with these new C_comp proposals,
we would have to give up on the idea of using measured data in the IBIS file.
The only way to generate some of these new C_comp models would be via
simulation, where you can probe nodes you can't physically probe.

Randy noted that he would give some more thought to cleaning up the BIRD and
removing some of the complexity.

- Mike L.: Motion to adjourn.
- Walter: Second.
- Arpad: Thank you all for joining.

AR: Walter to send out BIRD197.1 draft 1.

-------------
Next meeting: 11 December 2018 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
